For some time now, technology has advanced to the point where developers and manufacturers have had the ability to provide remote control over their products. A very simple example is a television and its remote controller. A remote controller uses a wireless signal, usually infrared, to send user provided control instructions to a television set. The television set then executes those instructions, such as turning off the television or changing the channel. In the case of the TV and the remote controller, manufacturers had to design, develop and program the remote controller such that it could interact with the proprietary specifications of their television system. A remote controller setup for one television system would not work for another television system or a different system all together, such as a DVD player.
With the wide proliferation of the devices connected to the internet, developers have had the ability to develop software and controllers to control devices connected to the internet. One example is a personal computer with remote desktop software. This software enables a personal computer (with the correct software) to control another personal computer which is connected to the internet and running the remote desktop software. Another example is a mechanical device which is fitted with integrated circuits (ICs) that can be controlled by smartphones such as AR.Drone, Sphero and iHelicopter. For situations like these, developers currently have to create or develop proprietary software to provide control functionality of proprietary hardware.
Control has also gone beyond the personal computer. Developers have designed and built micro control units (MCUs) integrated with remote communication devices and programmed them to receive instructions both locally and remotely.
In the past, the controlling device that sent the instructions to host devices may have been specifically manufactured and designed by the host device manufacturers. However, new devices, such as smart phones, remove the necessity of manufacturing the controlling device because these devices are very flexible and common place. These handheld devices are smaller than the traditional television remote controllers and can be configured with software to provide instructions to any object with a receiver. The only limitations are that an object has proper hardware and that the controlling device has the proper software.
A developer who wishes to provide remote controllability to an object or product they may also create, must spend time and expenses in developing the software and hardware for this remote controllability functionality. For example, a developer might have to fit their product with an application specific integrated circuit (ASIC) specifically designed to receive remote communications. The ASIC may have a proprietary set of commands and instructions that need to be programmed into a controller to remotely control and communicate with the ASIC and control the product. Additionally, for every different type of computer or operating system, a different program or application has to be created to ensure compatibility. Furthermore, the developer has to fabricate and test the ASIC to ensure that it is working properly. All of this deters manpower from the development of the host product itself. Furthermore, the developer has to develop software specific to the ASIC and any remote controlling device. Many times, devices that could be fitted with an ASIC to allow remote control are not because of the time and costs for implementation.
All currently available automation, integration and control products and technologies are nothing more than hardware and software acting as figurative ropes and pulleys designed to manipulate devices and constructs with abstraction for the actual state of the device itself. Consequently, these existing solutions require considerable customization and development on a case by case basis for the establishment of individual/closed automation and control ecosystems. These solutions are neither universal nor capable of ad-hoc deployment scenarios. From complex proprietary based control and automation systems to low cost, Do-It-Yourself (DIY) approaches, all currently available solutions require varying degrees of hardware and software abstraction to accomplish their respective deployment goals.
In general, all competing solutions fail to offer universal control as they all are predicated upon deployment through an abstraction layer and are geared towards specific markets of which there is no cross-communication or service. For the most part, competing solutions to the above described problems introduce automation of devices as “after thoughts” and attempt to enable integration through a “bolt on” metaphor. No competing technology has yet produced a universal “plug and play” model for any third party device manufacture to employ.
Current automation and control management systems and components are mired with complex controls, proprietary commands and non-intuitive interfaces. Entry level systems which attempt to empower the end user with some degree of management of the automation device are limited to very simplistic binary states such as a “preference list.” This limitation exists because there is no established mechanism for broadcasting the capabilities of the component or device.
True, universal automation and control is predicated upon the development of the integrated technology piece which will deliver plug and play for all devices and constructs that can be envisioned within an automated ecosystem. Historically, we have accepted that information and its movement through the internet have been viewed as unrestricted through the establishment of communication, messaging and interaction standards such as TCP, SMTP, and HTTP and we have viewed access to the same as commonplace due to the ubiquity of the web browser. These standards and related technologies not only assure access to information but are largely taken for granted as being available anywhere and through anything at any time.
Access to control however presents considerably greater challenges and to this day no single solution allows for the complete ad-hoc establishment and expansion of an automation plant without imposing the requirement of complex iterative development of said environment. Simply put, the seemingly contradictory expectation exists that while a printer added to a network should automatically be accessible to computers within the same network, it is also expected and accepted that a device added to an automation plant requires the reconfiguration of the totality of the automation systems for the specific recognition and operation of that singular new device.
The ideal connected world allows for equal access to information and control. The technology architects of the information age have achieved universal access to information set within this ideal yet they have only created successive obstacles to equal access to control. Each development within the automation and control space has been predicated upon the use of complex and proprietary interconnects creating virtual ropes and pulleys to the devices they intend to operate and manipulate. At no point in time have the endpoints been given the fundamental abilities to maintain their unique presence and identity in a networked infrastructure and present their modes of being for open access and manipulation. The existence of abstraction layers within the modes of address between end users and automation systems from automation systems and their endpoints assures that at no point may an end user alter, add or remove an endpoint without modifying the system that is to manage it. In effect, while access to information is always direct, the middleman in access to control becomes its liability and greatest detraction.
Additionally it is important to note that most automation invention in the “post PC revolution” has been product-centric, not technology centric. Constructs come into being through the amalgamation of a host of existing technologies and introduce very little that is “new.” In doing so, these developments effectively add complexity to the landscape they ostensibly intended to simplify.
Thus, a need has been developed for a system and method that simplifies and vertically integrates the development of the hardware and software for a universal control system. Such a system and method provides solutions to the above described problems by delivering integration from within a construct to be controlled rather than via an external abstraction layer. Moreover, such a system and method should imbue the integrated construct or device with an ability to broadcast its existence, its identity, its functionality as well as its current state and reciprocally receive instruction in parallel with its traditional I/O mechanisms. The present invention satisfies these and other needs.